Skip to content

Add initial MinGW support#60

Merged
seritools merged 4 commits into
rust9x:rust9xfrom
Jookia:jookia_mingw
Jun 28, 2026
Merged

Add initial MinGW support#60
seritools merged 4 commits into
rust9x:rust9xfrom
Jookia:jookia_mingw

Conversation

@Jookia

@Jookia Jookia commented Jun 27, 2026

Copy link
Copy Markdown

Here's the initial MinGW support. It is missing:

  • Unicows support (if this needs to be added to the compiler)
  • Fixed backtraces (requires work in the backtrace crate)
  • Testing for the x86_64 target

I will write up some instructions when it's a little more mature, hopefully that could be added to the wiki. I'm happy to write instructions for anyone for the purposes of testing and review.

@cher-nov cher-nov left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A note in the commit comment explaining why GetFileSize() is more backward-compatible than GetFileSizeEx() would be also great.

Comment thread library/std/src/sys/fs/windows.rs Outdated
Comment thread library/std/src/sys/random/linux.rs
Comment thread compiler/rustc_target/src/spec/base/windows_gnu.rs Outdated
Comment thread library/std/src/sys/fs/windows.rs Outdated
Comment thread src/bootstrap/src/core/build_steps/compile.rs
@Jookia

Jookia commented Jun 28, 2026

Copy link
Copy Markdown
Author

I've realized there's no i686-rust9x-windows-msvc target. Would it be okay to drop the i686-rust9x-windows-gnu target? That would leave only two new targets: i586-rust9x-windows-gnu and x86_64-rust9x-windows-gnu.

Edit: I was wrong, I missed it. Previous Jookia was right.

Comment thread src/bootstrap/src/core/sanity.rs
Jookia added 3 commits June 28, 2026 23:14
This commit introduces the following targets:

- x86_64-rust9x-windows-gnu: 64-bit Windows XP onwards
- i686-rust9x-windows-gnu: i686 Windows NT4/98 onwards
- i586-rust9x-windows-gnu: i586 Windows NT4/98 onwards

The MinGW target has a higher minimum OS version for a two reasons:

1. MSVCRT is expected to be shipped with the operating system
2. pthreads requires NT4 functions
An earlier Rust9x patch (see Fixes:) changes the function signature for
hashmap_random_keys. This breaks cross-compiling on Linux.

Modify the Linux code to use the new signature as a fix.

Fixes: cd6c320
The Rust bootstrap code currently tries to build the rtstartup objects
using a stage0 compiler because it's a bit more convenient.

The stage0 compiler doesn't know about rust9x targets so instruct it to
use a compiler we've built instead.
Windows Vista onwards implements APIs to handle initializing values
once. Use a double-lock on Rust9x for backwards compatibility.

@seritools seritools left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looking good! one small nit, otherwise good to go!

Comment on lines +147 to +148
let pending = self.pending.load(Acquire);
if pending == false {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: could store initialized instead, preventing the inverted logic here (and have the initial state be zero instead of 1)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kind of wanted to match the the logic from the other code but yeah I can update this.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah i see, that makes sense -- std Once also seems to agree:

/// Initialization has completed and all future calls should finish immediately.
/// By choosing this state as the all-zero state the `is_completed` check can be
/// a bit faster on some platforms.
const COMPLETE: Primitive = 0;

am convinced, can stay as is ^^

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, if !pending would be better I guess?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a somewhat stylistic choice but I wanted to match the other functions pending == c::FALSE.

If it really matters I can do a PR for it.

@Jookia

Jookia commented Jun 28, 2026

Copy link
Copy Markdown
Author

Alright! I'll give it a day or two to sit and fix the nit and anything else you think of. I'll open some other PRs in the mean time. If @cher-nov has any other input that would be good. :)

Comment on lines +147 to +148
let pending = self.pending.load(Acquire);
if pending == false {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah i see, that makes sense -- std Once also seems to agree:

/// Initialization has completed and all future calls should finish immediately.
/// By choosing this state as the all-zero state the `is_completed` check can be
/// a bit faster on some platforms.
const COMPLETE: Primitive = 0;

am convinced, can stay as is ^^

@seritools seritools merged commit be4391a into rust9x:rust9x Jun 28, 2026
@Jookia

Jookia commented Jun 28, 2026

Copy link
Copy Markdown
Author

Yay!

@Jookia Jookia deleted the jookia_mingw branch June 28, 2026 15:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants